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AUTOMATED GENERATION OF OLTP MESSAGE SOURCE CODE 



BACKGROUND 

Technical Field 

[0001] Embodiments of the invention generally relate to online transaction processing 
(OLTP) messages. More particularly, embodiments relate to the automated generation of source 
code for transforming payload messages into and out of an OLTP language. 

Discussion 

[0002] Gaming systems are in widespread use and continue to grow in popularity. For 
example, the use of point-of-sale terminals has expanded from traditional retail environments to 
a wide variety of non-traditional environments. Indeed, in some markets consumers can 
purchase lottery tickets online from the comfort of their own home or from a filling station pump 
while purchasing gas. 

[0003] A typical gaming system includes an application running at the location of the 
consumer, where the application is networked with a remote online transaction processing 
(OLTP) host. The OLTP host is responsible for managing the particular game being played and 
often operates under a proprietary, industry specific language. For example, one gaming system, 
which is commercially available from the GTech Rhode Island Corporation, implements an 
OLTP language that defines a specific and unique message structure that results in relatively 
dense byte arrays. The application, on the other hand, is typically a web-based program written 
in an objected-oriented program language, such as the Java language, that is incompatible with 
the OLTP language. Thus, in order for the application and the OLTP host to communicate with 
one another, messages between the application and the OLTP host must be transformed between 
the program language of the application and the OLTP language. Specialized source code is 
used to perform the message translation, where the source code is developed offline based on the 
protocols of the two languages. Once the message translation source code has been developed, it 
is used to process messages in real-time. There is therefore an offline process in which the code 
is developed, and an online process in which the code is used to transform messages in real-time. 
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[0004] Conventionally, the source code development process begins when human 
programmers having knowledge of both the program language and the OLTP language manually 
write source code for each type of message to be encountered. For example, a message from the 
application to the OLTP host requesting an online lottery wager might be defined as the message 
type "Lotto WagerRequest", whereas a message from the OLTP host responding to such a 
message might be defined as "WagerResponse". Thus, the programmers would generate a 
Lotto WagerRequest source code file and a WagerResponse source code file, where the 
Lotto WagerRequest file is able to transform messages from the program language of the 
application to the OLTP language and the WagerResponse file is able to transform messages 
from the OLTP language to the program language. Once the source code for a given type of 
message has been written, a program compiler compiles the source code into an executable 
format. 

[0005] The online process begins when a message parser receives a message in either the 
program language or the OLTP language and uses the compiled source code to transform the 
message between the program language and the OLTP language. For example, the above- 
described Lotto WagerRequest message from the application to the host would be transformed 
from the program language to the OLTP language (i.e., encoded). On the other hand, the 
WagerResponse message from the OLTP host to the application would be transformed from the 
OLTP message to the program language (i.e., decoded). 

[0006] Unfortunately, the manual labor associated with writing the source code for all of the 
possible message types typically takes months and therefore can have a significant effect on the 
development process. There is therefore a need to reduce the amount of time, labor and expense 
required to generate source code that is used to transform messages between a program language 
and an OLTP language. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0007] The various advantages of the embodiments of the present invention will become 
apparent to one skilled in the art by reading the following specification and appended claims, and 
by referencing the following drawings, in which: 

[0008] FIG. 1 is a block diagram of an example of a message processing architecture 
according to one embodiment of the invention; 
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[0009] FIG. 2 is a block diagram of an example of a message processing architecture 
according to an alternative embodiment of the invention; 

[0010] FIG. 3 is a flowchart of an example of a method of processing messages according to 
one embodiment of the invention; and 

[0011] FIG. 4 is a flowchart of an example of a method of generating source code according 
to one embodiment of the invention. 

DETAILED DESCRIPTION 

[0012] Systems, architectures and methods of processing messages provide for a significant 
reduction in the amount of time, labor and expense required in the development stages of a 
message transformation process. In one embodiment, a method of processing messages involves 
generating source code in a program language. The source code is compiled and the compiled 
source code is used to transform a payload message the program language and an online 
transaction processing (OLTP) language. The source code is generated automatically. 
[0013] In another embodiment, a method of generating source code involves receiving a 
markup language document, where the markup language document is compliant with message 
rules associated with an OLTP language. The markup language document is compiled into 
source code, where the source code enables transformation of a payload message between a 
program language and the OLTP language. 

[0014] In yet another embodiment, a message processing architecture includes a 
development module, a program compiler and a message parser. The development module 
generates source code in a program language and the program compiler compiles the source 
code. The message parser transforms a payload message between the program language and an 
OLTP language, where the development module generates the source code automatically. 
[0015] FIG. 1 shows a message processing architecture 10 that provides for a significant 
reduction in the amount of time and effort required in transforming messages between a program 
language and an OLTP language. While the message processing architecture 10 will be 
primarily described with regard to payload messages of a gaming system, the embodiments are 
not so limited. Indeed, any system in which OLTP development time is an issue of concern can 
benefit from the principles described herein. Notwithstanding, there are a number of aspects of 
gaming system payload messages for which the message processing architecture 10 is well 
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suited. For example, payload messages, which implement actual transactions between the 
application and the OLTP host, contribute significantly to the development time associated with 
a given system. 

[0016] Generally, message processing architecture 10 assists an application 34 in 
communicating with an OLTP host 36 so that application 34 and OLTP host 36 are able to 
communicate seamlessly and in real-time. The OLTP host 36 is typically a proprietary system 
that operates under an industry specific OLTP language. The application 34, on the other hand, 
can be a commercially available web-based program written in program language such as an 
object-oriented program language. In one example, the OLTP host 36 is a gaming system such 
as an online wagering system and the application 34 is a middleware program that performs 
various player data management operations. Since the language of the OLTP host 36 is 
generally incompatible with the language of the application 34, architecture 10 is needed. 
[0017] The illustrated message processing architecture 10 has a development module 12 that 
generates source code 14 in the program language of the application 34. A program compiler 16 
compiles the source code 14 such that compiled source code 18 results. A message parser 20 
transforms payload messages 22 (22a, 22b) between the program language and the OLTP 
language. Specifically, message parser 20 transforms request messages 22a from the program 
language to the OLTP language (i.e., encodes) and transforms response messages 22b from the 
OLTP language to the program language (i.e., decodes). Since the development module 12 
generates the source code 14 automatically, it has been determined that in certain environments 
source code 14 can be generated for all message types in a matter of weeks, where the same task 
takes months in conventional approaches. 

[0018] Specifically, the development module 12 receives a markup language document 24 
(24a, 24b) for each message in the OLTP language and compiles the markup documents 24 into 
the source code 14. Thus, source code 14 is generated for a plurality of message types. In the 
context of a gaming system, a type of request message could be a message requesting to place an 
online lottery wager, and a type of response message could be a message responding to a wager 
request. 

[0019] The markup language documents 24 are compliant with message rules 26, 28, where 
the message rules 26, 28 are associated generally with the OLTP language, and the source code 
14 enables transformation of messages 22 between the program language and the OLTP 
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language. In particular, the message rules 26, 28 define markup tags for describing components 
of the messages 22. For example, request message rules 26 might describe elements such as 
"encrypt", "checksum" and "length", as well as the attributes that can be used to define these 
elements in a markup language document. Similarly, response message rules 28 might define 
elements such as "decrypt" and "map", and the appropriate attribute rules. The markup language 
documents 24 can be generated by someone knowledgeable of the markup language in question. 
[0020] The development module 12 can further include a stylesheet parser 13, where the 
development module 12 uses the stylesheet parser 13 to compile the markup language documents 
24 based on stylesheet data 30, 32. The stylesheet data 30, 32 represent program templates for 
each type of message in the program language. As already discussed, the source code 14 
behaves differently depending on whether the message is a request message 22a that must be 
encoded or a response message 22b that must be decoded. Accordingly, the stylesheet data is 
partitioned into request stylesheet data 30 and response stylesheet data 32. 

[0021] It should be noted that the components of the architecture 10 may be located together, 
apart, or any combination thereof. For example, the development module 12 may be deployed at 
the location of the OLTP host, where the source code 14 is distributed to individuals and entities 
associated with application 34. In such a case, the application 34, message parser 20 and 
program compiler 16 may all be running on the same system. Alternatively, all of the 
components of the architecture 10 might be deployed at the OLTP host location, where the 
request and response messages 22 are sent to the message parser 20 over a network connection. 
The above examples are not all inclusive and are given merely to facilitate an understanding of 
the principles described herein. 

[0022] Turning now to FIG. 2, a particular example of a message processing system 10* is 
shown in which the program language is Java (Java 2 Platform, Enterprise Edition/J2EE; Java 2 
Platform, Standard Edition/J2SE). Other object-oriented languages such as C++ (C++ 2.1, 
Stroustramp et al., 1990) and Smalltalk (ANSI INCITS 319-1998, 2002) would have similar 
implementations. In the case of an object-oriented language such as Java, the compiled source 
code is a class file that generates either a byte array containing the encoded message, or a hash 
map that contains the decoded message. Generally, a hash map contains name-value pairs that 
are stored in a common data structure, where the data structure offers quick insertion and search 
capabilities. Thus, when an application needs to send a request message to the OLTP host (i.e., 
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encode a message), the application sends a hash map containing the appropriate name-value pairs 
to the message parser, which loads and executes the corresponding class file based on the type of 
message. The class file generates a byte array that complies with the OLTP language and the 
message parser returns the byte array to the application. 

[0023] When the application needs to read or process a response message from the OLTP 
host (i.e. decode a message), the application sends a byte array representing the response 
message to the message parser. The message parser parses the byte array, then loads and 
executes the appropriate class file based on the type of message. The class file generates a Java 
hash map that complies with the application program language. 

[0024] In the illustrated example, development module 12' uses stylesheet parser 13' such as 
the commercially available XSLT parser to generate source code 14 f in Java for a particular type 
of message. Java source code 14' is a *.java file. A Java compiler 16' such as the compiler in the 
commercially available Java Development Kit (JDK) compiles the Java source code 14 f to obtain 
compiled Java code 18\ The compiled Java code 18' is a *. class file and is used by message 
parser 20* to transform messages 22 between Java and the OLTP language. 
[0025] As already discussed, when application 34 needs to send a request message 22a' to 
the OLTP host (i.e., encode a message), the application 34 sends a hash map containing the 
appropriate name- value pairs to the message parser 20', which loads and executes the 
corresponding class file 18'. The class file 18' generates a byte array that complies with the 
OLTP language and the message parser 20' returns the byte array to the application. When the 
application needs to read or process a response message 22b' from the OLTP host 36 (i.e. decode 
a message), the application 34 sends a byte array representing the response message 22b' to the 
message parser 20'. The message parser 20' parses the byte array, then loads and executes the 
appropriate class file 18'. The class file 18' generates a Java hash map that complies with the 
application program language. 

[0026] Development module IT generates the Java source code 14 f automatically, based on 
markup language documents 24' (24a*, 24b f ) and stylesheet data 30', 32\ where the markup 
language documents 24 1 are extensible markup language (XML, 1.0 World Wide Web 
Consortium/W3C Recommendation, February 10, 1998) documents, and are compliant with 
message rules 26 1 , 28'. Automatic generation of the source code 14' significantly reduces the 
amount of time, labor and expense associated with the development of the overall system. 
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[0027] Turning now to FIG. 3, a method 38 of processing messages is shown. Method 38 
can be implemented using any combination of commercially available software and/or hardware 
techniques. For example, method 38 can be implemented as a set of instructions stored in a 
machine-readable medium such as read only memory (ROM), compact disk ROM (CD-ROM), 
electrically erasable programmable ROM (EEPROM), random access memory (RAM), etc. as a 
message processing architecture. Specifically, processing block 40 provides for automatically 
generating source code in a program language. The source code is compiled at block 42 and the 
compiled source code is used to transform a message between the program language and an 
OLTP language at block 44. 

[0028] FIG. 4 shows one approach to generating source code in greater detail at block 40 1 . 
Processing block 40 f can also be implemented as a set of instructions stored in a machine- 
readable medium, where the instructions are capable of being executed by a processor to 
generate source code. Specifically, processing block 46 provides for receiving a markup 
language document where the markup language document is compliant with message rules 
associated with the OLTP language. The markup language document is compiled into the source 
code at block 48. The source code enables transformation of the message between the program 
language and the OLTP language. 

[0029] Those skilled in the art can appreciate from the foregoing description that the broad 
techniques of the embodiments of the present invention can be implemented in a variety of 
forms. Therefore, while the embodiments of this invention have been described in connection 
with particular examples thereof, the true scope of the embodiments of the invention should not 
be so limited since other modifications will become apparent to the skilled practitioner upon a 
study of the drawings, specification, and following claims. 
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